• Введение
• Игровые жанры и типы перспективы
• Общие принципы создания игр: экшен-игры и стратегии
• Общие принципы создания игр: квесты, РПГ, спортивные игры, головоломки и симуляторы
• Создание персонажей, эскизов и проектной документации
• Создание головоломок
• Создание уровней
• Создание миссий
• Программирование
• Искусственный интеллект
• Игровая графика
• Анимация
• Интерфейс пользователя и управление игрой
• Звуковое оформление
• Музыка в играх
• Тестирование
• Маркетинг и работа с прессой
• Разработка веб-сайтов, посвященных играм
• Техническая поддержка и послепродажное обслуживание
• Сделай сам, или Великая Условно-Бесплатная Революция
• Как найти свое место в игровой индустрии
• Агенты и вербовщики
• G.O.D. - божественное откровение
• Школы для разработчиков
• Ресурсы по разработке игр в Интернете
• Важнейшие мероприятия, организации и награды
• Логотипы для магазинов

Программирование

В этой главе мы поговорим о самом важном в разработке игр - программировании.

Программирование, естественно, подразумевает и разработку как таковую, и собственно написание компьютерной программы, в нашем случае - самой игры или игрового движка. Задачи программиста: а) решить, что игра должна делать; б) понять, как она будет это делать; в) написать инструкции для ПК на языке, который ПК способен перевести в собственный язык и выполнить (например на Microsoft Visual C++).

А вот другое определение программирования: «Это самое интересное из того, чем можно заниматься, не раздеваясь... хотя одежда тоже не обязательна». (Ну да, с этим можно спорить, но именно такая формулировка приведена в словаре FOLDOC на веб-сайте www.instantweb.com/~foldoc/contents.html!)

Называйте их, как хотите: программерами, кодерами, перемалывателями чисел или алгоритмическими анализаторами, - факт остается фактом: программисты - это те самые ребята, которые создают основу любой игры. Представьте себе, что игра - это строящийся дом. Тогда программирование - это каркас, определяющий форму здания. Никакая роспись на стенах, никакая, даже самая удивительная музыка, не смогут заменить несущие конструкции. Игра, как и здание, должна возводиться на надежном фундаменте.

Чтобы писать игры, требуется нечто большее, чем диплом специалиста в области прикладной математики и пара собственных программок. Программирование игр невозможно без изворотливости ума, адского терпения и той непостижимой субстанции, что по-французски зовется savoir faire, то есть сноровкой, или, если угодно, хваткой, и вырабатывается многолетней практикой, дисциплиной и одержимым трудом.

Итак, приготовьтесь. Следующие три с лишним десятка страниц отданы асам программирования, которые согласились поделиться с нами своим многолетним опытом работы в индустрии и рассказать, как обойти подводные рифы этой, становящейся все более популярной, профессии.

Курт Арнлунд (Kurt Arnlund), Accolade

Перед тем как оставить Activision и стать ведущим программистом игры Slave Zero в компании Accolade, Курт Арнлунд работал над созданием таких бестселлеров, как Mechwarrior 2: NetMech, серия Interstate '76 и Heavy Gear. Курт говорит, что, приступая к написанию компьютерной игры, программист должен держать в голове три условия успешного завершения проекта: соблюдение баланса между сроками и желаниями, точность в постановке задач, выбор между кратчайшим и оптимальным путями решения проблем.

Компромисс между сроками и желаниями

Разработчик должен постоянно балансировать на тонкой грани между мечтами о «потрясающей игре, которая намного опередит современные технологии» и временем, отпущенным на создание этого шедевра. Громадье планов - типичная причина срыва проектных сроков, обычно укладывающихся в один год. А любая - даже полугодовая - задержка с выходом на рынок влечет за собой риск опоздать: конкуренты гарантированно уже выпустят что-нибудь подобное. Впрочем, проблема обоюдоостра: слишком занизив планку проекта, вы имеете все шансы выпустить игру, которая будет превзойдена конкурентами задолго до релиза вашего нетленного произведения.

Будьте конкретны, предельно конкретны

Одна из главных задач разработчика состоит в том, чтобы придумать великолепную игру, а затем предельно четко и точно изложить свои мысли на бумаге. После этого не остается ничего иного, как передать программисту проектную документацию - и вожделенно потирать руки: еще немного - и мечта станет реальностью. Увы. Программист, приступив к реализации проекта, обычно наталкивается на детали, которые вы не обговорили заранее. И здесь, надо заметить, мало что может вызвать такую же досаду, как небрежность разработчика при составлении проекта. В результате - потеря времени и производительности, ведь программист, обнаруживший недочет в документации, возможно, уже начал писать программу... Чем больше времени вы потратите на раскрытие мельчайших деталей своей идеи, тем меньше создадите проблем для всех остальных. А заодно, получите умопомрачительную игру.

Какой путь выбрать, кратчайший или оптимальный?

Программисты - люди в большинстве своем ленивые. Это так, и ничего с этим не поделаешь. Не верьте, если кто-то попытается убедить вас в обратном. Не замечали, мы почти инстинктивно пытаемся воспользоваться самой короткой дорогой из пункта «А» в пункт «Б»? Порой кратчайший путь - это единственное, что мы видим, приступая к выполнению задачи. Зачем я все это говорю? Так и быть, раскрою вам один маленький секрет. Кратчайший путь далеко не всегда лучший. Как ни жаль, но это правда. Чем больше вы, разработчик, руководитель проекта, понимаете в программировании, тем чаще сможете подходить к своему программисту и говорить: «Слушай, то, что ты тут сотворил, - это, конечно, здорово, но какого черта ты не сделал так-то и так-то? Я ведь именно этого хотел!» Еще лучше, если вы, уважаемый разработчик, действительно знаете, что хотите получить, и зададите конкретный способ реализации с самого начала.

Возможно, у вас появится искушение спросить нас, программистов: если вы знаете, что короткий путь не всегда лучший, то почему не обращаете внимание на действительно лучший путь? Отвечаю: только потому, что лучший путь не всегда является кратчайшим. Вообще-то, это не так уж и плохо, что большинство программистов рассуждают именно так, поскольку это означает, что работа будет сделана вовремя. Если бы при создании программного кода мы стремились к полному совершенству, то проект отнимал бы в три раза больше времени, и при этом он содержал бы только треть планировавшихся деталей. А ведь может быть и того хуже, как с игрой Trespasser, мы закончили ее с перерасходом бюджета и серьезным опозданием, игра просто блистала с технологической точки зрения, но была совсем неинтересной.

Справа показан пререндеренный (предварительно прорисованный) кадр из популярной игры Interstate '76 компании Activision. (Использовано с разрешения компании Activision, Inc.) Снизу - последняя работа Курта Арнлунда, игра Slave Zero компании Accolade. (Использовано с разрешения компании Accolade, Inc.)

А как насчет покупки готового программного ядра, уровня, например Quake II или Unreal? Или собственные разработки - более надежный способ вкладывания капитала?

Трудный вопрос. Я знаю нескольких программистов, которые даже мысли не допускают о лицензионных движках, справедливо полагая, что в этом случае лишатся возможности копаться во всевозможных захватывающих деталях ядра игры, которая им нравится. На мой же взгляд, это не так уж и важно. Если создавать программное ядро с нуля, придется прорабатывать массу технических деталей, от не всегда приятного общения с которыми вы освобождены в случае с лицензией. Лицензионный движок - это, как правило, быстрое создание работающих прототипов, однако со временем вы все равно столкнетесь с необходимостью изучения и, возможно, отладки всех деталей лицензионной технологии. Если, конечно, захотите выжать из нее все, на что она способна. А поскольку у каждого собственный стиль программирования, то лицензионный движок может показаться вам как абсолютно нечитаемым кодом, так и шедевром программирования. Но, скорее всего, это будет нечто среднее.

Далее Курт Арнлунд дает советы начинающим программистам, желающим влиться в игровую индустрию.

Прежде всего необходим соответствующий диплом. Нет-нет, модный и дорогой вуз вовсе не обязателен; просто постарайтесь найти место, где можно получить крепкие знания по математике и (немного) физике, и все будет в порядке.

Вот лучший совет, который я могу дать начинающему программисту: дружище, если ты действительно молишься на игры, ни в коем случае не оставляй своей цели! Посвяти в свои планы всех, кого только можно. Вдруг завтра тебе удастся переговорить с агентом из рекрутирующей фирмы, курирующим нашу индустрию, или, скажем, с программистом, непосредственно работающим в одной из игровых компаний. А еще поднакопи денег и обязательно посети Конференцию разработчиков игр (Game Developers Conference), либо устройся ее обслуживать в качестве волонтера, чтобы получить бесплатный доступ. Старайся общаться с как можно большим числом людей, занятых в этой области, и удача тебе улыбнется. Мне повезло, поскольку мой друг, пытавшийся найти такую же работу, рассказал обо мне агенту по найму...

«Многие начинали с тестирования игр, а со временем становились разработчиками или продюсерами. Главное - упорно идти к намеченной цели, и все получится», - заключает Курт Арнлунд.

Джей Стелли (Jay Stelly), Valve Software

Джей Стелли - старший инженер-программист Valve Software, талантливейшей команды дизайнеров, программистов, художников, аниматоров и звукорежиссеров, создавших Half-Life, одну из самых нашумевших игр 1998 года. Последняя на сегодня работа Джея - сетевая игра Team Fortress 2, выпущенная Valve и Sierra Studios.

Когда Джея попросили осветить те аспекты программирования игр, которые прежде всего будут полезны и важны для инженеров-программистов, он обрисовал общую ситуацию, уделив особое внимание вопросам скорости вывода изображения на экран и ограничения памяти, возникающих при включении в игру поддержки 3D-ускорителей. Все его примеры касаются движка Half-Life, построенного на технологии Quake/Quake II, которая первоначально была приобретена Valve у id Software, а затем в значительной мере переработана.

Программному ядру любой игры всегда присущи определенные технические ограничения. Некоторые из них, вроде предполагаемой платформы (процессор, объем ОЗУ, место на жестком диске и т.д.) и требуемых ею технических характеристик (скорость вывода графики, время загрузки и т.д.), вы можете определить сами, другие же обусловливаются оборудованием, которым располагает ваша аудитория. Конечно же, сделанный выбор будет иметь определенные последствия. Рассмотрим конкретный пример.

Half-Life поддерживает 3D-ускорители. Благодаря этому пользователи, располагающие соответствующей техникой, получили лучшее качество изображения и более высокую частоту кадров. Казалось бы, все просто, верно? Однако нам пришлось слегка попотеть...

Самая большая проблема состояла в том, что многие из представленных на рынке 3D-ускорителей располагали лишь 2 мегабайтами памяти для хранения текстур. Дело усугубляло то, что для большинства ускорителей затраты на подкачку новых текстур взамен старых были достаточно высоки, поэтому применение более 2 Мбайт памяти значительно снижало частоту кадров. Для Half-Life это означало, что каждая отдельная сцена в игре должна была использовать не более 2 Мбайт отображаемых текстур.

Программирование дает возможность снять некоторые из вышеперечисленных вопросов. Однако время, отведенное для написания программ, строго ограничено. Хороший инженер в состоянии оценить сложность проблемы и выбрать правильный подход к ее решению. Многие из принимаемых при создании игры решений диктуются необходимостью найти компромисс между различными техническими ограничениями. Именно так было и с Half-Life.

Уже на ранних этапах разработки в Valve осознали, что управление памятью текстур в случае 3D-плат выливается в серьезную проблему, главной причиной которой является 2-мегабайтное ограничение текстур на каждую сцену. Собственную текстуру имела не только окружающая обстановка, но и каждый персонаж, а также любой вид оружия, которым персонаж обладал. Задние планы вне помещений были полностью составлены из больших текстур. Кроме того, движок был разработан таким образом, что львиная часть данных по эффектам освещения в игре также хранилась в виде текстур. Воленс-ноленс, но нам пришлось тратить время, отведенное под программирование, на решение данного вопроса. Иначе б нам просто не хватило текстур для получения того качества изображения, к которому мы стремились! Фактически проблема оказалась значительно более серьезной, нежели простое ограничение в 2 Мбайт для некоторых плат. Выяснилось, что почти все 3D-платы, существовавшие на рынке на момент выпуска Half-Life, показывали разительное отличие в производительности в зависимости от объема памяти, используемой под текстуры, и того факта, складывается ли ваше изображение из текстур, чьи размеры являются степенью двойки.

Джей Стелли: «Инженер-ас, в отличие от заурядного инженера, видит вопрос в комплексе, целиком, что позволяет быстро локализовать важные проблемы и потратить время, отведенное под программирование, на их решение». (Приводится с разрешения компании Sierra Studios.)

В конце концов, мы создали набор приемов, которые позволили Half-Life использовать больший объем текстур и при этом эффективно работать с 2-мегабайтными 3D-платами. Художники переработали текстуру персонажей и элементов интерфейса, комбинируя несколько текстур в одну карту с размером, кратным степени двойки. Программисты добавили в ядро игры подсистему для управления палитрой текстур, которая позволила хранить большее количество текстур в том же объеме памяти, а также изменили части прорисовки, дабы по возможности рисовать все полигоны с одинаковой текстурой за один раз (с целью минимизации подкачки текстур). Ну а платы с недостатком памяти получили возможность автоматически упрощать текстуру (что, конечно, ухудшает качество изображения, но улучшает динамику).

Другое качество, отличающее хорошего инженера от посредственного, - способность правильно определить время на решение конкретной задачи. На нашу проблему можно было затратить как значительно больше, так и значительно меньше времени. Очень важно выбрать верные критерии оценки вариантов решения. За балансом времени, выделенного на программирование, необходимо следить в течение всего процесса создания игры. Не забывайте о приоритетах, ведь хорошие инженеры могут улучшить абсолютно любой фрагмент технологии, поработав над ним.

Я считаю, что правильная постановка задачи и верная оценка решений - два очень важных момента, которые выделяют Half-Life на фоне других игр.

Теперь о преимуществах и недостатках использования лицензионного движка. Стоит ли начинающему программисту пытаться создать движок самостоятельно? Джей Стелли считает, что принять в данном случае верное решение очень сложно, и важно знать, как ведется разработка.

Над созданием лучших 3D-движков трудятся коллективы опытных программистов, многие из которых заняты этим не первый год. Следовательно, результат представляет собой плод многолетних нелегких изысканий в данной области. Впрочем, даже те игры, которые не могут похвастаться движками уровня Quake III или Unreal Tournament, способны предъявить вам свидетельства того, что над их программным ядром трудились настоящие профессионалы. Иначе говоря, создание собственного движка, как правило, требует привлечения целой команды высококвалифицированных программистов, но нередко это выходит дешевле, чем покупка лицензии на готовый движок. Однако существуют определенные моменты, из-за которых использование лицензионных продуктов может оказаться предпочтительным, несмотря на увеличение затрат.

Во-первых, эти движки уже были в деле, а значит, они более надежны. Вы покупаете не только технологию, но и время, которое было затрачено на ее разработку и тестирование. Во-вторых, у ваших инженеров отныне есть время на построение собственно игры или поиск решений для преодоления технических ограничений купленного движка. В-третьих, использование лицензионным движков предоставляет преимущества в области маркетинга и найма. Покупатели, имевшие дело с играми на данном движке, априорно благосклонны к вашему проекту. Наконец, велика вероятность привлечения в команду специалистов, уже знакомых тонкостями заложенной в движке технологии. Не упускайте из виду и вполне очевидную возможность быстро создать работающий прототип игры.

В Интернете можно найти целый ряд ресурсов, полезных для программистов игр. Ниже приведен краткий список сайтов, заслуживающих наибольшего внимания. (Веб-сайты, посвященные разработке игр, перечислены в главе 24.)

• Game Programming MegaSite www.perplexed.com/GPMega

• Visual Basic Explorer www.vbexplorer.com

• Game Programming Galaxy www.geocities.com/SiliconValley/Vista/6774/

• Game Programming '99 www.gameprog.com

• New Game Programmer's Guild http://pages.vossnet.de/mgricken/newgpg/

• Amit's Game Programming Information http://www-cs-students.stanford.edu/-amitp/gameprog.html

• GameProgrammer.com www.gameprogrammer.com

• Viper's C/C++ Page www.europa.com/-viper

• rec.games.programmer (группа новостей)

Чарльз Гоу (Charles Gough), Bungle Software

Чарльз «Чаки» Гоу начал программировать в девять лет, когда отец показал ему основные команды Applesoft Basic на стареньком Apple IIe. Чаки не имел никакого отношения к прославленной стратегии Myth II: Soulblighter, выпущенной Bungle Software, зато в очень скором временя игроки получат возможность увидеть его работу в игре, которая «весной 2000 года ураганом распространится по планете и продвинет Bungie еще дальше по дороге мирового господства».

Чаки делится своими мыслями с начинающими программистами.

1. Как можно скорее создайте работающую версию игры. Чем раньше будут готовы движок и основные элементы, тем больше останется времени на проверку и шлифовку самой игры. Кроме того, и вашей команде, и издателям будет легче проникнуться, вашим видением игры, если они смогут ознакомиться с работающим прототипом.

2. Чтобы достичь цели, вы должны быть готовы на компромиссы в отношении собственного программного кода. Предположим, у вас появилась идея великолепного, совершенно уникального алгоритма прорисовки. Одна беда - он медленно работает, а значит - отвлекает от игры, отнимая время на свою доводку. Результат: вы теряете издателя. Комментарии излишни...

«Памятка разработчика» от Чаки:

Игра должна быть интересной. Например, если вы создаете РПГ, можно, конечно, отразить в ней всю правду жизни и заставить виртуальных персонажей есть, спать и ходить по нужде. Но кому это нужно? Если ваш герой умрет от запора, потому что вы не следили за счетчиком дерьма, это может показаться забавным, но только поначалу, потом все эти штучки наскучат. Вывод: стремление сделать игру интересной должно стать основным приоритетом. Новейшие и самые лучшие технологии не спасут, если игра окажется скучной.

Есть ли у Bungie примеры, подтверждающие данный совет?

Серия Myth! Блестящий пример применения этих правил к жанру, который за все предыдущее время претерпел лишь минимальные изменения. До Myth все стратегии в реальном времени обязательно содержали достаточно длинный период возведения построек, и только после этого начиналось сражение, на которое вы не могли оказать никакого влияния, кроме как изменяя число и рода войск, вовлеченных в драку. Так вот, команда, работавшая над Myth, увидела огромный потенциал в собственно битвах, сделав основной упор на тактику сражения. Лучше всех имевший представление о том, как это должно выглядеть, Джейсон Джонс (Jason Jones) написал простую демонстрационную программу, состоящую из крошечной 3D-карты, гнома-гренадера, отряда нежити, вооруженного топорами, и базового движка, отражающего законы физики. Поначалу он планировал использовать полигональные 3D-модели персонажей и объектов, но вскоре понял, что, во-первых, это резко снизит частоту кадров, а во-вторых, на разработку движка уйдет слишком много времени. Тогда Джейсон изменил спрайтовый код из игры Marathon и использовал его для быстрого создания демо-версии. И что вы думаете? Такого простого начала хватило, чтобы попасть на обложку журнала Computer Game Strategy Plus...

Необходимость компромисса (между сроками, бюджетом, самой игрой и используемыми технологиями) - лейтмотив данной главы. Пришлось ли при создании Myth II: Soulblighter столкнуться с обычными трудностями, возникающими при написании любой игры?

Главная проблема состояла в том, что игру нужно было выпустить меньше, чем через год после выхода первой части. Естественно, ребятам хотелось «изменить, улучшить, добавить», но очень скоро стало ясно, что на все это нет времени. Зато они сосредоточились на самых ударных идеях - на поиске путей, интерфейсе и стрельбе. А вот от реализации таких вещей, как создание персонажей, полностью составленных из полигонов, «недвуногих» юнитов (кавалерия и катапульты), а также горящих деревьев и прочих «красивостей» пришлось отказаться.

Когда Чаки спросили, какие справочные материалы он считает полезными для начинающих игровых программистов, он ответил, что превыше всего ценит общение с опытными кодерами и изучение их программ. «Нет ничего лучше, чем поговорить с тем, кто уже написал несколько игр, или посмотреть настоящие исходные коды...» Программистам, не располагающим такой возможностью, Чаки советует читать книги, второй по значимости полезный источник, особенно университетские учебники, хотя и добавляет, что «найти среди них хорошие довольно трудно».

Майкл Д. Макграт (Michael D. McGrath), Dynamix/Sierra

Майкл Макграт - инженер-программист компании Dynamix. Он работал над созданием популярного симулятора воздушных сражений времен Первой мировой войны Red Baron 3D, а в прошлом участвовал в ряде других проектов, включая Netrek (свободно распространяемая программа) и Extreme Warfare (Trilobyte). Майкл предлагает вашему вниманию несколько советов, касающихся программирования и разработки игр, и перечисляет наиболее распространенные грубые ошибки, встречающиеся в игровой индустрии.

Сначала разработка, затем программирование

Лучший способ никогда не закончить игру - это сесть и попытаться сходу написать ее программу. Само собой, большинство дипломированных программистов способны на такой подвиг, но если вам не удалось завершить работу за относительно короткий промежуток времени, вас ожидает кошмарная перспектива использовать уже написанный код в качестве «руководства для разработки». Хороший дизайнер детально продумывает каждый аспект своего продукта задолго до того, как кто-то приступит к написанию кода, поскольку технические (и не только технические) решения, которые приходится принимать в процессе разработки, в значительной мере определяются конкретной задачей. Мне приходилось слышать о проектах (а иногда и принимать в них участие), которые никогда не были завершены или выбивались из графика не потому, что программисты не знали, что они делают, а потому, что ведущие инженеры и дизайнеры, очевидно, не имели представления, что именно они создавали, практически до момента выпуска игры. Проекты следует продумывать заблаговременно, в противном случае - готовьтесь платить за свое небрежение в будущем.

Но люди есть люди, и всегда, даже среди ваших коллег, найдутся такие, которые не понимают важности этого аспекта. Поэтому, прежде чем начинать проект, хорошенько присмотритесь к тем, с кем собираетесь работать, и убедитесь, что они разделяют ваши взгляды. К сожалению, многие из начинающих программистов, стремящихся в игровую индустрию, особенно те, кто бросил вуз ради того, чтобы поскорее начать писать игры, обладают совершенно недостаточными навыками программирования, необходимыми для эффективной работы над крупными игровыми проектами. Эти люди рано или поздно понимают, что программирование - всего лишь инструмент, используемый инженерами для реализации проектов. Инженерные навыки действительно необходимы. Практически каждый в этой индустрии является по крайней мере компетентным программистом. Что возвращает нас к подпункту 1 совета «А»: закончите учебу, если вы еще не сделали этого.

Научитесь сначала думать, а потом действовать.

Изучите свою аудиторию и конкурентов

Тем, кто не играет в игры, не следует пытаться их писать. Вообще, если вы не играете в игры, не стоит заниматься чем-либо, связанным с индустрией игр, за исключением, быть может, косвенной поддержки. Знание законов, по которым живет индустрия, образа мышления аудитории и возможностей, которыми обладают конкуренты, критически важно для создания высококачественных, успешных игр. Кроме того, необходимо понимать, в каком именно жанре вы можете проявить себя как разработчик. Определите, за какими играми вы готовы просиживать сутки напролет, - это как раз тот жанр, работая над которым вы принесете максимум пользы.

Не настаивайте на том, что сможете создать успешный шутер от первого лица, если всю жизнь играли в летные симуляторы и лишь недавно впервые попробовали пострелять, и вам это понравилось. Для работы над любой игрой необходимо знать все последние достижения в этом жанре и быть в состоянии оценить любую предлагаемую идею. Только в том случае, если вы можете предаваться воспоминаниям о «старом добром времени» с людьми, которые с первого дня поклоняются данному конкретному жанру, вы готовы нести свой шедевр в массы. Иначе вас хватит лишь на очередной клон, и вы затеряетесь в переполненном рыбешками море, чтобы в итоге быть съеденным какой-нибудь акулой, которая в отличие от вас всегда готовила уроки.

Это относится ко всем, но особенно к программистам. Программисты вдыхают в игру жизнь, и ни замечательная текстура, ни трехмерная графика, ни эпический сюжет не помогут, если программа не представит все это игроку должным образом. Чтобы понять, как подать эту замечательную историю, вы должны хорошо знать все прошлые работы, причем как победы, так и поражения. Другого пути нет и никогда не будет. Точка.

Когда программисты и другие члены команды трудятся над игрой, которая интересна лично им, дело идет быстрее и лучше. Для команды, работающей над проектом, я бы приравнял наличие подобного энтузиазма таланту и мастерству, вместе взятым. Запомните, это (в значительной степени) позволит создать высококачественный продукт.

Техника - это еще не все

Не следует думать, что вы сделаете все самостоятельно только потому, что можете писать программы с бешеной скоростью, по 1000 строк в день, и любите игры. Написать компьютерную игру - это все равно, что рассказать историю, - и хотя самого «рассказчика» создают программисты, без хорошего сюжета для рассказа не обойтись. Яркое художественное оформление, захватывающий сюжет, надежный движок, качественные режимы многопользовательской игры, не говоря уже о вдохновляющей музыке, - для хорошей игры требуется многое. И чтобы, взявшись за проект, довести его до конца, вам необходимо вникнуть во все эти детали, или хотя бы уверенно в них ориентироваться.

А чтобы постичь все тонкости представления различных элементов игры, вам необходимо понять их реализацию в среде, которую вы используете для того, чтобы рассказать историю. Однобитный графический поток позволяет получить замечательную частоту кадров, однако я сомневаюсь, что кто-нибудь по достоинству оценит визуальные эффекты вашей игры, решись вы использовать подобное программное ядро. Отчасти понимание того, что значит правильно рассказать хорошую историю, приходит с опытом - обычно возрастающим, если вы не ленитесь играть в чужие игры.

Наконец, необходимо уметь работать с людьми, которые помогают вам (как любой член команды, создающей игру) рассказывать эти истории. Вам необходимо иметь хорошие инструменты, необходимо научить остальных всему, что они должны знать, чтобы работать с вашей технологией, а прежде всего вам необходимо иметь терпение и решительность для того, чтобы выполнить все вышеперечисленное. И сохранять их до конца.

В нашей индустрии нет места для начальников-наполеонов, а также людей с высокомерным или замкнутым характером. Само собой, подобные типы появляются время от времени, но их игра находит свое последнее пристанище на полке для уцененных товаров (там же, к сожалению, заканчивается их карьера, а также карьера тех, кто с ними работал)... или, еще хуже, игра вообще не выходит на рынок. Если вы вдруг почувствуете, что работаете на кого-то, а не с кем-то, немедленно уходите, потому что в «смертельной схватке» на поле боя, именуемом «рынок игр», вы - на проигрывающей стороне.

Майкл Макграт поясняет свои советы на примере игры Red Baron II компании Dynamix и проблем, так замучивших ее программистов.

Red Baron II - типичный пример избытка технических переделок и недостатка предвидения в процессе разработки. В Red Baron 3D большая часть программистской работы состояла в вылавливании ошибок и попытках разобраться в коде, чтобы мы могли добавить в игру новые возможности и технологии. Когда началась переработка Red Baron 3D, создававшие игру инженеры или уже покинули Dynamix, или перешли в другие проекты. Код был плохо документирован, из-за чего мы столкнулись с нескончаемыми трудностями, связанными с его переработкой, и не было никого, кто мог бы помочь в нем разобраться. Переделать игру было бы гораздо проще (я уверен, что первоначальной команде это было по силам), если бы программа была хорошо структурирована. Но код, будучи плодом труда многих и многих людей, которые совсем не заботились о том, чтобы снабдить его хоть сколько-нибудь приличным описанием, был ужасающе загадочен. В дополнение к этому, в тех местах, где проект все-таки был хорошо продуман, код был сверхабстрактен и сверхтехничен.

Игре Red Baron II очень не повезло. Изначально разработанная под DOS, позже она переделывалась сначала под Windows 95, потом под DirectX и, наконец, под 3D-платы. В итоге код игры перекраивался столько раз, что под конец стал невообразимо громоздким. Основная проблема заключалась не в самой реконструкции, а скорее в том, что технология привела, как оказалось, к «переоценке» возможностей повторного использования кода и нарушению модульности. Вырезая некоторые части, приходилось сохранять остальные, склеивая их кое-как. В результате программу стало очень трудно читать и понимать. Если бы код с самого начала был хорошо продуман и выстроен по модульному принципу, то игра могла быть завершена гораздо быстрее, независимо от преимуществ технологии, которые вдохновляли на внесение изменений. Не следует понимать это утверждение в том смысле, что «нужно было использовать Си++». Мы пользовались этим языком. Однако объектно-ориентированное программирование со всеми его достоинствами может стать настоящим кошмаром при злоупотреблении плохо продуманным проектом и применением техники «заплаток». Никогда не позволяйте «завораживающим» возможностям языков программирования убедить вас, что соблюдение принципа «бритвы Оккама» и удобочитаемость программы уже не существенны. Никогда.

Уильям Оккам, философ, живший в 13-14 веках, вывел закон экономии, известный сегодня как «бритва Оккама». Вот его формулировка: следует отказываться от понятий, не являющихся необходимыми.

В дополнение к общению с другими специалистами через Usenet и посещению различных конференций Майкл Макграт предлагает несколько полезных книг, на которые стоит обратить внимание желающим заняться программированием игр:

• Computer Graphics: Principles and Practice, Second Edition in С. Авторы Foley, van Dam, Feinern Hughes (Addison-Wesley, 1996)

• Руководство по программированию («красная книга») и справочник OpenGL («синяя книга»)

• Серия The Graphics Gems, под редакцией Andrew S. Glassner, James Arvo, David Kirk, Alan W. Paeth и Paul S. Heckbert (Academic Press и АР Professional, 1993-1995)

• Artificial Intelligence. Автор Patrick Henry Winston (Addison-Wesley, 1992)

В настоящее время Майкл Макграт занят написанием программного кода для игр Desert Fighters и Aces of the Pacific II, а в его планах на будущее - переписать Netrek и возобновить участие в создании научно-фантастических боевых летных симуляторов и стратегических игр.

Аллен Джексон (Allen Jackson), Origin Systems

Аллен Джексон работал в компании Origin в течение ряда лет, и ему посчастливилось принимать участие в создании многих экшен-игр и космических симуляторов, отмеченных разнообразными наградами. В их числе: Crusader: No Remorse, Crusader: No Regret, Wing Commander Prophecy и Wing Commander Prophecy: Secret Ops. В первую очередь Аллен имеет дело с игровым кодом высокого уровня, а именно с разработкой интерфейса, приложениями Win32 GUI, объектами, определяемыми в игре, и сетевыми вопросами.

В данном разделе Аллен Джексон делится тремя советами по написанию кода для игр, ссылаясь при этом на свои последние работы, на практике подтверждающие предлагаемые рекомендации.

Используйте движок, управляемый данными

Ядро игры должно, насколько это возможно, работать на основе данных. Вместо того чтобы корпеть над каждым отдельным эпизодом игры, предоставьте программе самой подобрать нужную комбинацию элементов. Например, космические корабли в Wing Commander: Prophecy в основном создавались как элементы данных. Программисты определяют общие свойства кораблей: двигатель, пушки, ракеты, щиты и максимальное ускорение. Затем дизайнеры собирают файл данных корабля, который описывает его внешний вид, свойства и статистику. Этот файл будет позже прочитан с жесткого диска и проинтерпретирован программой. Лишь иногда программа ищет конкретный корабль для применения специальных эффектов, но в идеале и эти случаи следует убрать из кода, чтобы все корабли могли обладать теми или иными свойствами.

Еще один способ представить движок на основе данных - это система триггеров, привязанных к карте. Главный герой Crusader: No Remorse - десантник далекого будущего, бегающий по изометрической карте и расстреливающий врагов. Карта заполнена объектами, с которыми наш морпех может взаимодействовать, - телепортерами, дверями, выключателями и мониторами. Система позволяет дизайнеру выбрать определенный триггер (например переключатель) и присоединить к нему команду, например «открыть дверь №21». Эта связь сохраняется в файле карты и интерпретируется программой во время выполнения. Если система триггеров создана правильно, она позволит активизировать множество действий, в том числе и те, которые не были изначально запланированы.

Миссии тоже, по возможности, должны управляться данными. Программа не должна знать, какие конкретно миссии используются в сюжете, ей достаточно иметь каркас, позволяющий дизайнеру создавать сценарии кампаний и отдельных миссий, - то, с чем имеет дело конечный пользователь, игрок. Проектировщик миссий и сюжета Wing Commander: Prophecy позволяет дизайнерам создавать файлы «сериалов», которые содержат указатели общего сюжета, наборы миссий и древовидную структуру, связывающую все миссии воедино. Такая система чрезвычайно гибка и надежна, она позволяет создавать разные типы ветвей дерева и условий, что приводит к многообразию сюжетов.

Экспериментируйте с существующими движками

Один из самых важных аспектов в работе игрового программиста над любым приложением - это структуры и иерархии классов. Если интерфейс программ низкого уровня написан правильно, последующие стадии программирования будут проходить более гладко. Например, если в середине разработки вы решите что-то изменить в сетевой версии игры, вам потребуется лишь переписать модули низкого уровня, непосредственно отвечающие за поддержку сети. Остальным программам высокого уровня должно быть все равно, какие именно низкоуровневые программы обеспечивают их работу.

В Интернете существует множество прекрасных графических движков, готовых к употреблению. Загрузите любой и попытайтесь создать с его помощью простое приложение. Затем постарайтесь разобраться, какая архитектура заложена в движок. К примеру, существует множество вариантов прорисовки сцен. Некоторые движки позволяют создавать игровые объекты, а затем добавляют или удаляют их при прорисовке. Другие предпочитают, чтобы объекты сами себя рисовали с помощью класса screen. Третьи движки одновременно прорисовывают несколько сцен, используя систему окон. Наконец, некоторые программы накладывают объекты на сцену слоями в особом порядке, оставляя основной экран интерфейса самым последним, чтобы он всегда был виден.

Ряд игровых компаний открыли доступ к исходным кодам своих старых игр. Хотя вас, скорее всего, не заинтересует прямое использование их архаичных и потерявших блеск движков, вы можете захотеть исследовать основной цикл игры, механизмы ввода данных, передачу сообщений внутри игры, обработчик объектов, инструменты отладки и систему прорисовки игрового мира.

Один из примеров предложения исходного кода игры через Интернет - продукция компаний Raven Software и Activision, опубликовавших исходные тексты Heretic и Hexen для бесплатного использования. Загрузить их можно с узла www2.ravensoft.com/source. Не стала прятать свои исходные коды и id Software, выложившая в Интернет код Quake.

Избегайте статических классов и переменных

Аллен Джексон предостерегает от опасности попадания в «ловушку памяти» при использовании статических классов и приводит пример программы, демонстрирующей альтернативный способ обойти это часто встречающееся программистам препятствие.

Статические переменные подобны глобальным, так как они доступны из большинства классов, но одновременно может существовать только один экземпляр такой переменной. Существует несколько классов, таких как ClassOperatingSystem, ClassGameSound и ClassFileSystem, которые действительно подразумевают наличие единственного экземпляра класса. Некоторые другие классы выглядят так, будто для них тоже должен существовать только один экземпляр, хотя иногда допускается наличие и нескольких экземпляров. Классический пример подобного статического класса - ClassGameWorld:

class ClassGameWorld
{
public:

// статические данные игрового мира
static void* m_GameWorldData;

// статические компоненты-функции
static bool Install(void);
static bool Remove(void);
static bool AddObject(GameObject& _obj);

};

После определения класса программист мог использовать функцию World::AddObject() в любом месте в своих модулях, что удобно, но позволяет работать только с одним игровым миром. Если в дальнейшем замысел игры изменится и потребуется наличие многих игровых миров (например в случае большой сетевой игры), придется кардинально переписывать весь код игры.

Более правильным решением будет создать нестатическую версию класса ClassGameWorld, а затем завести статический шаблон списка игровых миров где-нибудь еще, например в классе ClassGame:

class ClassGame
{
private:

static TemplateList<ClassGameWorld*> m_GameWorldList;

…

public:

static ClassGameWorld& GetWorld(int _nWorld);

};

Это позволит программе иметь доступ ко многим экземплярам данного класса и в то же время сохранить только одно место для доступа ко всем данным игровых миров.

В главе 3 приведены общие советы Аллена Джексона по разработке игр.

Рагнар Шейерман (Ragnar Scheuermann), Wombat Games

Рагнар Шейерман работал в Origin Systems в качестве инженера-программиста над Ultima: Ascension и Ultima Online. Позднее он оставил Origin, чтобы стать ведущим инженером-программистом, дизайнером и вице-президентом компании Wombat Games.

Рагнар подчеркивает, что его советы в равной степени будут полезны как начинающим игровым программистам, так и новичкам-разработчикам, и сопровождает их примерами из собственного опыта.

Во-первых, убедитесь, что вы знаете игру, над которой собираетесь работать. Так, вы должны четко представлять, каким образом будете в нее играть. При этом ваше знание не должно быть секретом для вашей команды, и, как только вы придете к единому пониманию игры, скажите «стоп!» всем дальнейшим переделкам игровой концепции.

Во-вторых, максимальная отдача и инициатива возможны только в коллективах, влюбленных в свою работу. Если вы только начинаете проект, вам придется использовать все доступные стимулы, чтобы суметь его завершить. Я также обнаружил, что порой самое лучшее в играх - это «дополнения», введенные программистами или дизайнерами не потому, что их обязывает долг, а потому, что им хочется это сделать.

Наконец, если вы новичок, не пытайтесь сразу же прыгнуть выше головы. Не бойтесь пометить некоторые части проекта как необязательные, в первую очередь сосредоточьтесь на основных элементах. Выберите технологию, которая соответствует жанру создаваемой игры. Например, если ваша игра может обойтись без трехмерности (да и вам самому это 3D не нравится), не обращайте внимание на моду, другие вам не указ.

Рагнар Шейерман приводит примеры, помогающие лучше понять предыдущие замечания.

Работа над Ultima Ascension велась почти шесть лет. Основная причина столь рекордной продолжительности состоит в том, что каждый год авторы меняли концепцию игры, в силу чего всякий раз приходилось выбрасывать значительную часть кода. Изначально игра базировалась на движке Ultima 8, но с графикой высокого разрешения (позже этот движок был использован для игры Crusader). Но затем, как раз перед моим приходом в компанию, было решено, что вся графика станет полигонной, что означало использование абсолютно нового движка, новых инструментов и обучение команды программистов, у которой до этого практически не было опыта работы с трехмерной графикой.

Через полтора года большая часть команды была переброшена на Ultima Online, чтобы помочь в завершении этого проекта. Аккурат в это время один из программистов добавил в игру поддержку 3D-ускорителей. В качестве побочного эффекта этого шага было принято решение изменить перспективу камеры с изометрической на вид «из-за плеча» (как в Tomb Raider). Само собой, это разрушило часть модулей движка, потребовало переработки многих областей, не соответствующих новому положению камеры, и подготовило почву для следующего ключевого изменения. Сразу после выхода Ultima Online команда Ultima: Ascension была собрана вновь, но с новыми продюсером и ведущим дизайнером. Это привело к еще большему отходу от традиций Ultima 7, к более динамичной и активной игре. Работа над проектом пошла под девизом: «Больше удовольствия в каждые 30 секунд». Через год продюсер был уволен.

К этому моменту игра и управление проектом изменились до неузнаваемости, а от первоначальной команды (которая работала во время моего прихода) остались только шестеро бойцов: продюсер Ричард Гэрриот (Richard Garriott), программисты Герман Миллер (Herman Miller), Гэри Скотт Смит (Gary Scott Smith) и Чак Зок (Chuck Zoch), художники Скотт Джонс (Scott Jones) и Майкл Морлан (Michael Morlan). Движок... опять был переписан, и игра снова изменила направление, восстановив изначальные РПГ-черты. Вывод: проблемы с Ultima IX: Ascension возникли не потому, что проект не был хорош, а потому, что замыслы постоянно менялись.

А вот Ultima Online пострадала от недостаточно ясного видения игры, хотя и не так сильно. Концепция этого проекта никогда подробно не обсуждалась, поэтому игра выглядела по-разному в головах разных членов команды. Одни работали над имитацией виртуального мира, другие - над квестом, третьи находились под влиянием Diablo. Куда больше игра претерпела от того, что вдруг изменились требования к тестированию, и вместо 100 тестеров на каждую миссию понадобилось 2500. К сожалению, срок завершения игры при этом остался прежним, и сокращать время пришлось за счет программистов, а не дизайнеров. В результате мы имеем то, что имеем: вышедшую с опозданием, полную ошибок игру, не имеющую явно выраженного жанрового направления. Код получился чрезвычайно сложным для использования, а все программисты, начинавшие его писать, покинули команду.

Сейчас мы работаем над новой игрой и прилагаем огромные усилия, чтобы дать ей хороший старт и все же реализовать возможности масштабной сетевой игры ролевого типа. Мы создаем виртуальный мир, где ничто не предписано заранее, а его главные обитатели - сами игроки. К слову, при проведении собеседования с кандидатами на участие в проекте наиболее важным был вопрос: «Согласны ли вы с подобной концепцией игры?»

Завершая разговор, Рагнар Шейерман вновь вернулся к проблеме концепции игры, сказав, что «тратит уйму усилий на построение желаемой технологической базы до начала работ над собственно игрой». Причины этого изложены выше. «Чтобы не пришлось ничего переделывать по мере появления текущих проблем».

Мэтт Притчард (Matt Pritchard), Ensemble Studios

Должность Мэтта Притчарда в Ensemble Studios - специалист по графическому движку и оптимизации. Мэтт участвовал в программировании Age of Empires, а в момент написания этой книги был всецело поглощен работой над Age of Empires II: The Age of Kings. Несмотря на плотный рабочий график, Мэтт нашел время, чтобы сказать несколько слов тем, кто мечтает программировать игры. Итак, о каких трех самых важных вещах должен помнить программист?

1. Невозможно написать эпическую сагу за ночь; упорство и настойчивость - вот лучшие инструменты.

2. Большинство задач уже было решено до вас; посмотрите, чему можно научиться у других.

3. Большинство проектов так и не завершается. Излишние амбиции и отсутствие реалистичной оценки возникающих задач обрекают их на скорое забвение. Правильно оценивайте себя и соизмеряйте свои желания с реальными возможностями.

С какой самой сложной проблемой может столкнуться игровой программист? Мэтт Притчард делит программистские «тяготы» на две части.

• Идти в ногу с современными технологиями. Единственный способ добиться этого - сосредоточиться на самом важном, не жалея сил и времени на постоянное совершенствование.

• Строго контролировать ход работ. Программы должны создаваться вовремя и в соответствии с планом. Это приходит с опытом. Не вычеркивайте из помощников и соответствующую литературу по написанию надежного и «окончательного» кода. А вообще, это постоянная борьба, избежать которой, похоже, не удается никому.

В заключение Мэтт советует программистам, работающим над играми, выделить какую-то часть времени на регулярное и внимательное чтение группы новостей rec.games.programmer в Usenet, отражающей всю необходимую информацию о создании и совершенствовании игровых программ.

Чэд Фримен (Chad Freeman), Dreamforge Intertainment

Чэд Фримен - ведущий программист студии Dreamforge Intertainment, выпустившей в 1998 году великолепный квест Sanitarium. До этого проекта Чэд работал над играми Anvil of Dawn и Warwind.

В данном разделе Чэд предлагает игровым программистам несколько бесплатных советов и даже образец программы.

Вам, возможно, приходилось слышать, что при написании игровых программ одним из основных критериев является эффективность кода. Не верьте этому ни на минуту! Лишь для 10-20% вашей программы эффективность может оказаться критичной. Остальной код должен быть гибким, поскольку вам придется много раз его изменять. В противном случае, если код окажется слишком хрупок, чтобы допускать изменения, игра получится «второсортной».

Не стесняйтесь использовать что-либо по той только причине, что это придумано не вами. Многие замечательные решения, примененные в 3D-играх, основаны на технологиях, созданных для программ трехмерной визуализации несколькими годами ранее. Потратьте немного времени на исследование технических приемов, которые вы хотели бы использовать в своей игре. Впоследствии это освободит вас для размышлений над по-настоящему уникальными аспектами игры.

Самое важное на первых порах - довести хоть что-нибудь до конца. Способность завершить игру - вот то, что будет отличать вас от тех героев, что начали, но не смогли... Один из моих приятелей, программист, любит повторять: «Завершить игру невозможно, можно лишь прекратить над ней работать». Всегда найдется что-то, что улучшит код, но однажды надо набраться смелости и сказать: «Хватит, он уже достаточно хорош», - и оставить игру в покое.

Я обнаружил один полезный технический прием при работе с Си++, который заключается в использовании массивов вместо динамического выделения памяти всюду, где только можно. Вы можете реализовать любую общую структуру данных (списки, очереди, стеки, кучи, деревья), используя массивы, - для этого достаточно применить индекс массива в качестве указателя. Это сразу же устранит связанные со структурой данных проблемы утечки памяти и, что существенно, среди прочих выгод заставит вас продумать худшие варианты условий выполнения вашей программы.

Ниже представлен пример реализации связанного списка через массив с указателем в сравнении с вариантом использования динамической памяти, а также небольшой пример, где противопоставлены эффективность и гибкость.

Пример массива:

При использовании указателей и динамического выделения памяти связанный список может выглядеть примерно так:

Содержимое адресов памяти
001 [Указатель на первый элемент (010)]
002 [Указатель на последний элемент (062)]

...

010 [Указатель на графическое представление объекта]
011 [Здоровье]
012 [Указатель на следующий элемент (053)]

...

053 [Указатель на графическое представление объекта]
054 [Здоровье]
055 [Указатель на следующий элемент (098)]

...

062 [Указатель на графическое представление объекта]
063 [Здоровье]
064 [Указатель на NULL (конец списка)]

...

098 [Указатель на графическое представление объекта]
099 [Здоровье]
100 [Указатель на следующий элемент (062)]

Если вы забудете освободить одну из этих структур, занимаемая ею память будет потеряна до момента выхода из игры. Кроме того, эти структуры разбросаны по всей памяти, так что независимо от порядка просмотра списка без подкачки обойтись не удастся.

При использовании массива реализация может выглядеть следующим образом:

Заголовок списка:

Первый [индекс первого объекта - 001]
Последний [индекс последнего объекта - 003]

Список:

Индекс массива - данные - индекс следующего элемента

001 Данные объекта 1 002
002 Данные объекта 4 004
003 Данные объекта 2 -1
004 Данные объекта 3 003

Применяя массив, невозможно потерять ни бита памяти, поскольку у вас всегда будет целиком заполненный массив - не более и не менее. Кроме того, если ваша функция добавляет объект в список, находя первое пустое место в массиве, можно просмотреть весь список по порядку с первого элемента по последний, сохраняя связность буфера.

При использовании этого метода в игре Warwind было задействовано множество списков, и все они имели дело с одним массивом. Общий модуль выполнял просмотр массива сверху донизу. Когда нам было необходимо выполнить обработку для конкретного игрока, мы просматривали список объектов данного игрока. Когда должна была выполняться обработка для некоторых типов элементов, мы просматривали соответствующий список и так далее.

И еще несколько слов о гибкости:

Это то, с чем вы сталкиваетесь всякий раз, когда создаете игру. По сути, программируя, вы пытаетесь предсказать будущее и неизбежно делаете предположения, которые в дальнейшем окажутся неверными. Однако предположения могут быть как хорошими, так и плохими. В Warwind мы решили, что каждая машина должна иметь точное представление о состоянии игры в каждом кадре. Это было неудачное предположение, поскольку в Интернете, где время ожидания велико, а потеря пакетов - обычное дело, синхронизация каждого кадра замедляет игру до скорости улитки.

Чтобы знать все о компании Dreamforge Intertainment, ее служащих и играх, обратитесь на веб-сайт www.dreamforge.com.

Стюарт Денман (Stuart Denman), Surreal Software

Стюарт Денман - вице-президент и технический директор Surreal Software, многообещающей компании, ответственной за игру Drakan (издатель Psygnosis).

Не чужой в программировании, Стюарт утверждает, что одним из наиболее важных критериев при создании экшен-игр является скорость вывода графики на экран. Ниже перечислены три основных потребителя памяти, чье влияние на частоту кадров вас вряд ли устроит, если только вы скрупулезно над ними не поработаете.

Количество полигонов и минимальные системные требования

Для тестирования лучше всего использовать компьютер, оснащенный по самому минимуму. Только в этом случае вы будете уверены, что игра покажет себя паинькой даже на слабых машинах. (Для примера: уровень, демонстрирующий 30 кадров в секунду на Pentium II 400 МГц, на Р166 при том же числе полигонов будет выводиться со скоростью 8 кадров/с.) Необходимо найти баланс между внешним видом игры (больше полигонов) и ощущениями от нее (частота кадров). Выбросите из головы мысли о том, что сможете провести оптимизацию частоты кадров по ходу проекта.

Искусственный интеллект

Искусственный интеллект загружает процессор не слабее полигонов. Сцена с 30 врагами в пределах одного экрана не только увеличивает количество обрабатываемой видеоинформации, но и резко повышает объем вычислений искусственного интеллекта, отвечающего за всю эту прорву компьютерных существ. Вывод: программисты, занятые искусственным интеллектом, просто обязаны установить ограничение на количество персонажей в игре.

Освещение

В Drakan точечное освещение изменяющихся объектов и ландшафта вычислялось динамическим образом. Иначе говоря, любое перемещение источника света или объекта должно было пересчитываться. При этом чем больше источников света и чем большие площади они охватывают, тем, разумеется, медленнее идет игра. Обратное справедливо.

Кроме того, объясняет Стюарт, чтобы выиграть в скорости игры, там, где это возможно, необходимо снизить уровень детализации моделей (к примеру, меньше полигонов на удаленных объектах), а также убедиться, что базы данных и параметры организованы эффективно (как, конечно же, это было в игре Drakan).

В базах данных хранятся звуки, описания поведения, модели, текстуры и ресурсы сценария. Четкая организация этих элементов крайне важна для того, чтобы команда могла эффективно работать над уровнями. В игре Drakan поведение любого объекта определяется конкретными параметрами. Кроме того, существует отображение между ресурсами в базе данных и программным кодом, поэтому важно, чтобы все параметры задавались надлежащим образом.

Далее Стюарт Денман обсуждает аргументы «за» и «против» работы с лицензированным или собственным движком.

Приобретать лицензию или нет, зависит от той цели, которую вы себе поставили. Если вы решили сказать новое слово в технологии, то заемный движок не самое лучшее решение. Если же ваши планы не простираются дальше создания игры на основе оригинального сценария, лицензионный движок тут как тут. Лицензирование сэкономит годы работы и позволит уделить внимание самой игре.

Surreal повезло, поскольку мы добились начального финансирования проекта, имея на руках лишь небольшую демонстрационную программку. Большинству разработчиков это не удается. Я осознал (хотя и не сразу), что попасть в эту индустрию, если вы никогда в ней не работали, весьма трудно. Вам необходимо доказать собственную состоятельность либо с помощью репутации, либо поразив всех гениальной демо-программой. Жаждущие получить заказ на создание игры всегда могут появиться из ниоткуда и с ходу выдать демо-версию, соперничающую с профессиональными работами. Пока такое возможно, а значит, шансы есть у всех

В программировании информация часто хранится в виде массивов, то есть строк данных. Нередко попытка обращения к областям памяти находящимся за пределами массивов, вызывает общий сбой Windows - General Protection Fault (GPF). Например, если массив содержит только пять элементов, а программа попытается получить доступ к восьмому, вы увидите на экране сообщение о GPF. Чтобы застраховать себя от подобных ошибок, обратите внимание на следующую программу.

Это должен сделать каждый программист - создать шаблон для массивов. Не используйте массивы в стиле Си, если это не является абсолютно необходимым. Определение шаблона должно выглядеть примерно так:

template <class Entry> class Array
{
private:

Entry *pEntry;
int iSize;

Далее шаблон содержит внутренние компоненты для добавления (размещения) и удаления записей массива, а также компоненты для доступа к массиву, подобные приведенному ниже:

public:

// Обеспечивает доступ к записям массива...
Entry &operator [](const int ilndex) const
{

Assert(ilndex >= 0 && ilndex < iSize);
return pEntry[ilndex];

}

Функция Assert очень важна, так как она вызывает ошибку отладки, если значение выражения-аргумента Assert равно FALSE. Этот небольшой фрагмент программы спас нас от такого количества ошибок, что я просто не представляю, что бы мы без него делали. Наш макрос Assert выглядит примерно так:

// Режим отладки:
#if defined(_DEBUG)

extern BOOL MyAssertFunc(BOOL, int, char *};

#define NatBreakf) { _asm { int 3 } }

// Утверждает, что значение ехр - истина.
#define Assert(ехр) \

if (MyAssertFunc((int)(exp),__LINE__,__FILE__)) \
NatBreak();

// Режим без отладки:

#else

#define Assert(exp)

#endif // _DEBUG

При окончательной сборке все макросы Assert исключаются из компиляции. При сборке для отладки функция MyAssertFunc включается в библиотеку. Функция вычисляет первый аргумент и выводит окно сообщения, указывающее строку и файл, где сработало утверждение (последние два аргумента). После этого программист может принять решение продолжить или прервать выполнение. При выборе прерывания функция возвращает значение TRUE, и инструкция int 3 приведет к остановке отладчика на строке макроса Assert.

Узнать все о проекте Drakan вы сможете, заглянув на сайт www.psygnosis.com/drakan/.

Ричард Моу (Richard Moe), Humongous Entertainment

Ричард Моу, сотрудник компании Humongous Entertainment, привык выступать в самых разных амплуа: от руководителя проекта до (помимо прочих обязанностей) инженера-программиста. Все игры Humongous пишутся на собственном языке SCUMM, который был разработан соучредителем компании Роном Гилбертом (Ron Gilbert). Вот лишь некоторые проекты, отмеченные вниманием дизайнера и программиста Ричарда Моу (в хронологическом порядке): Junior Field Trips: Let's Explore the Airport, Pajama Sam in There's No Need to Hide When It's Dark Outside, Backyard Baseball и Putt-Putt Enters the Race.

Ричард утверждает, что каждая игра ставит перед дизайнером и программистом собственный набор проблем. Ниже он приводит примеры из своей практики.

При создании детских игр самое проблематичное - определиться со сложностью, чтобы игра получилась интересной и легкой как для четырехлетнего, так и для восьмилетнего ребенка. Очевидно, что уровень мастерства игроков в пределах этого возрастного диапазона существенно отличается. Например, в Pajama Sam входит простая игра типа крестиков-ноликов, Cheese and Crackers («Сыр и печенье»). Для игры используются доски трех размеров: 3x3, 5x5 и 7x7. Доска 3x3 - это классические крестики-нолики, три знака в ряд выигрывают. На досках 5x5 и 7x7 для выигрыша требуется поставить в ряд соответственно четыре или пять знаков. Легко понять, что первый из трех вариантов самый простой (меньше комбинаций), а остальные последовательно сложнее. Однако включив в игру все варианты, мы предоставили возможность приятно провести время игрокам с любыми навыками. Более того, оппонент в лице компьютера пытается подстроиться под возможности противника. Если игрок побеждает, в следующей партии компьютер будет играть более умело. Аналогично, если победа на стороне искусственного интеллекта, в следующей партии он будет играть чуть слабее.

А теперь небольшое отступление. Я считаю, что для игрового дизайнера, в отличие от программиста, самые главные вопросы - это знание аудитории, которой предназначается игра, и современных технологий. Первый пункт связан с предыдущим абзацем: работаешь для детей - обязан знать, что они любят; делаешь стратегическую игру на военно-историческую тему - будь любезен выяснить вкусы игроков, предпочитающих военные игры.

Очевидно, хороший программист должен постоянно следить за современными технологиями. Однако следует помнить, что эпоха Возрождения давно прошла, а вместе с ней исчезли и универсалы: сегодня быть программистом «на все руки» просто невозможно. Специализация обязательна. Уважающий себя игровой программист в первую очередь сосредотачивает внимание на областях, где чувствует себя сильнее всего, а остальное оставляет кому-нибудь другому. Я не смог бы написать хорошую подпрограмму для копирования большого массива битов из одной области памяти в другую, даже если б от этого зависела моя жизнь. Я - но не другие. Поэтому я предоставляю им делать их работу, а сам пользуюсь созданной ими библиотекой.

Должен ли программист разбираться в других областях «игростроения»?

Бюджет - страшная вещь. Действительно, по ходу проекта программисту часто приходится становиться мастером на все руки - что делать, специалистов не хватает. В других случаях возникающая проблема является уникальной для игры и используемого движка. Я не могу поручить человеку, хорошо знающему Си++, написать подпрограмму, которую можно будет использовать в моей игре, основанной на языке SCUMM. В этом случае незнакомый со спецификой инструментария программист может не справиться с заданием (чаще всего именно так и происходит). К слову, совсем недавно я столкнулся с подобной проблемой во время работы над Putt-Putt Enters the Race. В конце игры игрок должен провести свой автомобильчик (Putt-Putt) по псевдотрехмерной трассе. Чтобы все это правильно работало, я должен был отслеживать объекты в трехмерном виде. У меня не было практически никакого опыта в трехмерных преобразованиях, а рядом, увы, не оказалось ни одного человека, который мог бы прийти мне на помощь. В итоге ваш покорный слуга был вынужден делать все самостоятельно. К счастью, у меня есть несколько знакомых специалистов, и результаты оказались удовлетворительными. Конечно, это не Gran Turismo, но давайте вспомним основной вопрос: я понял, что мою аудиторию (дети 3-8 лет) не волнует реальность физических моделей и трехмерная визуализация в реальном времени. Вместо этого я поместил несколько забавно выглядящих уток, которые должны были крякать и улетать, если вы подъезжали к ним слишком близко.

А как лучше всего научиться программированию? «Зажмите нос и ныряйте прямо на самую глубину, - советует Ричард. - Начните с простого - игры вроде Minesweeper или тетриса. Или с клона Space Invaders. Еще немного, и вы доберетесь до трехмерных экшен-стратегий от третьего лица в реальном времени».

Курт Пфайфер (Kurt Pfeifer), Cavedog

Cavedog Entertainment - компания-партнер Humongous Entertainment, разработавшая в свое время стратегическую игру Total Annihilation, которая имела умопомрачительные продажи и была отмечена невероятным количеством наград со всего мира. Знакомьтесь: Курт Пфайфер, один из авторов Total Annihilation. Кроме того, в его послужном списке Microsoft Soccer, Powerslave, DinoPark Tycoon и Magic School Bus Across the Solar System, а также перенос Duke Nukem 3D на приставку Sega Saturn. На момент написания книги он занимал должность ведущего программиста проекта Good & Evil (увы, закрытого вместе с Cavedog в начале 2000 года. События в игровом мире происходят с невероятной быстротой. И не всегда приятные. - Примеч. ред.). Ниже Курт предлагает несколько полезных рекомендаций для тех, кто хочет заняться написанием программ для современных игр.

Подготовьте полный проект своей игры

Если вы хотите уложиться в запланированные сроки, прежде всего четко определите, что и как нужно получить в результате. «Игрописание» не столь сухо и канонично, как точные науки, здесь гораздо больше простора для импровизации, чем в любой другой области программирования. Но если вы в состоянии хотя бы приблизительно объяснить, что хотите в итоге получить, это позволит в будущем избежать работы вслепую и необоснованных задержек. Будет полезным даже просто просмотреть эскизы и сценарий – это даст вам возможность составить общее представление об игре, а также позволит подобрать оптимальный вид игры на экране (перспектива, двухмерная или трехмерная графика).

Курт приводит следующий пример:

Меньше всего вопросов, когда вы заняты переносом существующей игры на другую платформу. Так было, когда мы портировали Duke Nukem 3D и Quake на Sega Saturn (я тогда работал в Lobotomy): вместо проекта на бумаге, который мог быть изменен или неверно истолкован, у нас был ясный прототип в виде игры для ПК, которая к тому времени уже покорила рынок. Каждая картинка, каждый звук, каждый нюанс системы управления были уже готовы, оставалось лишь вписать все это в рамки, накладываемые приставкой Saturn. На все работы нам дали шесть месяцев (позже срок был увеличен до девяти, что позволило запрограммировать сетевую версию) и это заставило нас трудиться с максимальной эффективностью. Понимание «общей картины» игры позволило нам оптимально распределить задачи и спланировать график выполнения проекта.

Вовлекайте в работу как можно больше людей

Это проще сказать, чем сделать, так как программированию игр почти не учат, а вам необходимо найти людей с уже имеющимся опытом (таких всегда дефицит) или выбрать из тех, кто знает общее программирование и горит желанием погрузиться в игры. В такой ситуации даже простейшие задачи могут перерасти в фундаментальные и, если вы испытываете недостаток в рабочей силе, все сроки полетят в тартарары.

Выделяйте время на исследования и разработку

К сожалению, из-за жестких сроков сдачи проектов время для исследований выделяется нечасто. Если вы хотите сделать что-нибудь действительно уникальное, найдите возможность провести некоторые изыскания, в ходе которых можно будет подобрать готовые пакеты программ, отвечающие вашим потребностям (инструменты трехмерного моделирования, программы рисования, звуковые редакторы), а также создать необходимые собственные инструменты (редакторы карт, языки сценариев, инструменты для анимации и т.п.). В это же время художники, взяв за основу существующие инструменты трехмерной анимации и двумерного рисования, могут заняться созданием видеороликов (или отдельных рекламных кадров), моделирующих перспективу игры и ее динамику. В этом случае вы сразу сможете выяснить, все ли согласны с проектом, который вам предстоит воплощать, вместо того чтобы через пару лет вдруг обнаружить, что издатель или дизайнер видят игру совсем иначе, чем вы предполагали.

По мнению Курта Пфайфера очень важно поддерживать в коллективе, работающем над игрой, интерес к проекту, что в конечном итоге позволит довести дело до конца.

Я не раз видел, как дизайнер терял интерес к игре после первой половины проекта, когда «медовый месяц» начального проектирования уже прошел и настало время перейти к проработке «скучных» деталей. В этом случае я был вынужден брать на себя еще и роль дизайнера: ком забот рос, и в результате в той или иной степени начинало хромать программирование. Что касается завершения проекта, то сегодня потерпеть поражение проще, чем когда-либо: игры (и их бюджеты) становятся все больше, а списки технологических возможностей растут как на дрожжах.

В заключение Курт говорит: «Даже простое управление проектом может оказаться нелегкой задачей, однако игра в любом случае должна и может быть завершена. Если, конечно, вы заранее спланировали всю работу и должным образом распределили задания».

Джейми Фристром (Jamie Fristrom), Treyarch Invention

Джейми Фристром - старший программист в калифорнийской компании Treyarch Invention. Создание знаменитых экшен-игр Die by the Sword и Limb from Limb (издатель Interplay, 1998) - отчасти и его заслуга. Джейми делится с нами парой мыслей относительно программирования игр и модульности разработки.

Это настоящее искусство - написать исходный код, который совместит в себе сразу множество качеств. Программа должна быть не только легко читаемой, поддерживаемой и развиваемой, но и давать возможность быстро создать работающую демо-версию.

По сути, программист - это человек, который помогает дизайнеру в работе над игрой или уровнем игры. Поймите это, и игра только выиграет от такого подхода к делу.

Самое неприятное, когда в ходе работы возникает необходимость внести в игру новые, не запланированные ранее возможности. В случае с Die by the Sword примером такого рода может служить вдруг возникшая идея применения в качестве орудия оторванной конечности. Лучший способ справиться с этим - наверное, переписать инфраструктуру и добавить в нее новые возможности, но мы, помнится, просто скрестили пальцы и быстренько пропатчили исходную программу. Разумеется, это привело к массе огорчений и долгим часам отлова ошибок-«жучков», нами же и занесенных.

Поэтому последний совет Джейми Фристрома звучит так: «Насекомые в программе - это плохо. Давите их до того, как они начнут размножаться».

Майкл Саладино (Michael Saladino), Presto Studios

После ухода из компании Mobeus Designs, занимающейся созданием трехмерных графических движков, Майкл Саладино некоторое время работал в Volition (на ее счету игра Descent, слышали?), где вскоре стал ведущим программистом. В данный момент он снова программирует движки в Presto Studios. Ниже следует список заповедей, предложенных Майклом, и комментарии к каждой из них.

Нельзя недооценивать ассемблер

С появлением каждого нового поколения процессоров Intel в интернетовских группах новостей и курилках фирм, занимающихся разработкой ПО, вновь разгораются дискуссии относительно будущего языка ассемблер. Идея написать игру для ПК целиком на ассемблере уже никогда не осуществится, однако это вовсе не означает, что ассемблер перестал быть чрезвычайно полезным инструментом программирования. Интенсивно выполняющиеся циклы, которые потребляют львиную долю общего времени выполнения игры, всегда будут существовать в той или иной форме. Раньше они использовались для копирования больших битовых массивов, сейчас применяются для внутренних циклов отображения текстур. Что же дальше? Как насчет триангуляции сплайновых персонажей в реальном времени? Блок программы, который выполняет цикл сотни, тысячи или сотни тысяч раз для каждого кадра, часто будет работать гораздо быстрее, если он написан на ассемблере.

Я еще не встречал компиляторов, способных понять тонкие нюансы фрагмента программы так же хорошо, как опытный программист.

Как следствие: не следует надеяться, что применение ассемблера - это уже победа. Медленному алгоритму уготовано медленное выполнение как на ассемблере, так и на Си. Поэтому начинать всегда следует с оптимизации алгоритма. Если вы уверены, что нашли лучшее решение (либо если начался завершающий этап работы над проектом и продюсер не позволяет вам переписывать алгоритм обрезки полигонов в пятый раз), попробуйте применить ассемблер с целью выжать последние капли быстродействия.

Если же вы считаете, что игра не стоит свеч, то представьте себе, как вытянется ваше лицо, когда вы узнаете, что в команде конкурентов нашлись программисты, думающие иначе, а их игра выполняется несколько быстрее, что позволило использовать эти умопомрачительные точечные эффекты...

Не стоит оптимизировать программу раньше времени

Не занимайтесь оптимизацией раздела исходного кода до тех пор, пока не убедитесь, что он значительно замедляет выполнение. В противном случае вы сами, во-первых, потеряете на этом время, а во-вторых, замедлите разработку программы в будущем, когда другим потребуется разбираться в вашем фрагменте на ассемблере. Вот несколько классических примеров.

Оптимизация кода инициализации

Зачем это нужно? Он запускается один раз в начале программы. Разумеется, если из-за предварительной обработки крупных текстур запуск игры занимает полминуты, тогда что-то сделать нужно (скажем, вынести эту задачу как отдельный шаг в обработке уровней), но в 99,9% случаев, если код выполняется всего один раз, вообще не стоит об этом беспокоиться.

Оптимизация до анализа

С моим опытом в программировании, уходящим далеко в прошлое (я впервые сел за Apple II+ в семь лет), я по-прежнему часто ошибаюсь в определении, что замедляет, а что не замедляет мой код. К счастью, профайлеры (особенно VTune от Intel) стали обычным инструментом программирования. Они помогут вам быстро и легко определить, какие функции и даже какие строки являются причиной того, что ваш код выполняется столь вяло. После подобного анализа вы наверняка никогда не будете расточать время, оптимизируя что-то, что и так работает достаточно быстро.

Оптимизация быстрых программ

Вам никогда не попадались программисты, занятые преобразованием отлично читаемых программ на Си в крайне неуклюжие (хотя, возможно, и очень умные) программы на ассемблере, хотя все уже гарантированно работает с частотой 120 кадров в секунду? А мне попадались. Понятно желание сделать код настолько быстрым, насколько это в принципе возможно, но это уж слишком. Не стоит забывать и о том, что код должен легко читаться, что особенно актуально в современных компаниях, занимающихся разработкой ПО (вполне вероятно, что к тому или иному фрагменту вашей программы будут обращаться десятки людей). В большинстве случаев введение в игру кода, написанного на ассемблере, на начальной стадии реализации проекта является плохой идеей. Это сильно затрудняет обновление и дополнение программы.

Любите свою программу, но не обожествляйте ее

Невозможно даже приблизительно сказать, сколько времени тратится на подобные глупости! Программисты так привязываются к своему коду, что закрывают глаза на любые его недостатки. Писать программы - это, конечно, здорово, но не забывайте, что они, в конечном счете, всего лишь буковки на экране. Недостатки вашего кода - вовсе не ваши недостатки, не принимайте их на свой счет. Просто согласитесь с тем, что кто-то другой придумал, как заставить вашу программу работать быстрее. И с этого момента маленький прием, показанный вам другим человеком, стал и вашим тоже.

Кроме того, не устраивайте разборок насчет стилистических разногласий. Когда я слышу очередной спор по поводу того, использовать ли в тексте программы табуляцию или пробелы, мне кажется, что я готов вскрыть себе вены. Меня не волнует, как вы расставите свои пробелы или скобки, для меня важно исключительно содержание программы. Я думаю, каждая компания должна принять одно из двух решений: либо каждый пишет в своем стиле и никому не позволяется выражать по этому поводу недовольство, либо все должны придерживаться единожды принятого стандарта.

И вообще, программистам необходимо уметь отделять себя от своих программ.

Тодд Джонсон (Todd Johnson), Oddworld Inhabitants

Инженер-программист Тодд Джонсон работал в свое время над играми для Genesis (Sylvester n' Tweety in Cagey Capers, Demolition Man и Izzy's Olympic Quest) и PSX (Oddworld: Abe's Oddysee и Oddworld: Abe's Exoddus). Тодд считает, что самое важное для программиста - учитывать ограничения конечной системы. Он поясняет свою мысль:

Я начинал с игр для приставок, где мы постоянно мучились от недостатка оперативной памяти. Например, Oddworld: Abe's Exoddus должен постоянно подкачивать в ОЗУ анимацию, фоновые рисунки и даже фрагменты программы. А на ПК вы, вероятно, столкнетесь с проблемами быстродействия. В любом случае конечная система так или иначе влияет на игру.

«Во-вторых, уважайте игрока, - говорит Тодд, - в конце концов, это он платит за игру».

Иначе говоря, не стоит увлекаться излишним усложнением. Когда мы впервые начали работать над мудоканами (игра Oddworld: Abe's Exoddus), каждый из них обладал индивидуальными чертами характера и должен был реагировать по-разному. С точки же зрения игрока, их реакция казалась абсолютно случайной, так как внешне все они выглядели одинаково. Мы сохранили эмоции, но отбросили идею индивидуальности.

И последнее, что советует Тодд Джонсон: «Продумайте повторное использование кода».

На написание программы по готовому проекту требуется время, поэтому если игра перегружена уникальными возможностями, ее реализация займет годы. Другая крайность - полное однообразие, так что хитрость в том, чтобы найти оптимум. Добавляя простые параметры (например скорость или время) к существующим персонажам и механизмам, вы сможете извлечь массу преимуществ.

Что Тодд считает самым большим препятствием в работе программиста?

Коммуникационную пропасть между членами команды. Причем это не только наша проблема, те же несовершенства мучают бизнес в целом. В каждом проекте участвуют программисты, художники и дизайнеры, каждая группа обладает индивидуальностью и имеет свой собственный опыт. Конечно, гораздо проще наладить взаимодействие в пределах группы, чем вне ее, но именно в этом ключ к успешной реализации проекта. В школах, к сожалению, не обучают общению с людьми, а тем более с людьми, чье видение мира отличается от вашего.

Гонзо Суарес (Gonzo Suarez), Pyro Studios

Гонзо Суарес работает в компании Pyro Studios, которую основал в 1997 году вместе с другом и партнером по бизнесу Игнасио Пересом (Ignacio Perez). Именно здесь, в Испании, родилась игра Commandos: Behind Enemy Lines, ставшая позже международным бестселлером (издатель Eidos Interactive).

Гонзо Суарес делает ряд полезных подсказок начинающим программистам, только-только собирающимся приступить к созданию первой игры.

Прежде всего спросите себя: в какую игру ты хочешь играть? Вопрос кажется очевидным, но покрывает добрых 90% проблем, которые возникнут в ходе разработки. Как ни странно, в большинстве случаев ответ на этот вопрос выпаливают, не задумываясь (хотел бы я уметь отвечать так же быстро), однако обычно этот ответ сразу же вызывает беспокойство. «Это экшен-игра с элементами стратегии и духом приключений, и она отображает 30000 полигонов!..» Довольно странно, когда ответ на вопрос «в какую игру ты хочешь играть?» начинается со слов «это...», а уж упоминание о числе полигонов достойно пера Кафки.

Надеяться, что ответ останется неизменным на протяжении всего проекта, - роскошь, которая может быть подкреплена только опытом (не только знанием проблем, сопутствующих созданию видеоигр, но также пониманием их влияния на процесс разработки). В большинстве случаев на любую неясность будет искаться оправдание типа «открытого дизайна» и «привлекательности для всех», но для меня это прямой путь к самоубийству.

Примером могут служить Quake II и Half-Life. Кажется, что эти игры очень похожи, однако акценты, сделанные на том, где, как и когда нужно стрелять в Half-Life, контрастируют с быстрым окружением движущихся мишеней и точным прицелом Quake II, чувство силы оружия в игре id Software противопоставляется возможностям Half-Life скрываться от противника и снайперских выстрелов. Все это делает стратегию сетевой игры для них абсолютно различной.

В процессе работы над игрой возникают затруднительные ситуации, когда необходимо принести в жертву одну из конфликтующих возможностей, хотя каждая из них по своему хороша и при желании можно отстоять любую. Другими словами, мы все хотим получить самую красивую машину с наиболее мощным двигателем, минимальным расходом топлива и за наименьшую цену, но при разной расстановке приоритетов мы можем получить любую машину, начиная с BMW и кончая гоночным суперкаром или семейным лимузином.

Имея за плечами примерно пятнадцатилетний опыт программирования и разработки игр, Гонзо Суарес советует обратить внимание на следующие правила.

Игра

Основные элементы, которые образуют игровую логику, являются неприкосновенными для прочих моментов игры. Например, критерии логики игры предписывали, чтобы вся графика Age of Empires была согласована с основной сеткой игрового пространства. Другими словами, игровые объекты занимают одну или несколько клеток. Они никогда не могут занимать клетку совместно с другими объектами или размещаться между двумя клетками. Расстояния и координаты в логике игры измеряются по сетке. Поэтому графика должна следовать тем же самым правилам (более или менее скрытым). Несмотря на эти жертвы в области графики, у нас получилась выдающаяся игра, которая не смогла бы достигнуть такого успеха, если бы в процессе создания не была сохранена верность данным приоритетам.

Другим примером игровой логики является Commandos. Логический мир игры подразделяется на произвольные секторы с любым перемещением объектов в непрерывном трехмерном пространстве, при этом объект хранит информацию о своей трехмерной координате. Именно эта логика позволила создать столь нестандартную игровую графику (с помощью команды замечательных художников, конечно).

Логический интерфейс

Не менее важна проблема взаимосвязи логических элементов игры между пользователем и компьютером. Хорошим примером является курсор, при помощи которого пользователь получает доступ в игровой мир.

Все, что включено в игру, должно взаимодействовать с пользователем (более или менее явно) наиболее эффективным способом; любые действия, которые пользователь захочет совершить в игре, должны выполняться достаточно просто, без привлечения интуиции. Другими словами: а) если пользователь не может чего-то понять, это что-то лучше вообще исключить из игры; б) если пользователь не может выполнить какую-либо операцию, исключите ее из списка действий (особенно если она выглядит для игрока заманчиво).

Ощущение и отчуждение

Эти факторы включают в себя как элементы, посредством которых игра передает игроку ощущения (визуальные и звуковые), так и возможность игры создать для игрока атмосферу погружения, в которой он почувствует себя внутри игры.

И хотя игроки, по-видимому, ценят этот фактор больше всего, я бы поставил его на третье место по шкале приоритетов. Иначе после входа в игру вас ждет пять минут благоговения, а затем часы разочарования. Это, как правило, происходит, когда разработчик создал замечательный движок с уникальными возможностями, которые кажутся ему настолько привлекательными, что он не может отказать себе в удовольствии использовать их где надо и не надо, даже если они совсем не сочетаются с логикой игры.

Примеры таких проектов (некоторые из которых никогда не были завершены) у всех на слуху. Их программисты были безумно горды реалистичной и детальной физической моделью, где все вращалось и сталкивалось - ну прямо как в реальной жизни. Но когда эти потрясающие возможности применялись в игре, вдруг выяснялось, что вы не можете управлять персонажами, и ваше первоначальное любопытство вскоре превращалось в форменный кошмар. В качестве крайнего случая попробуйте представить себе игру в шахматы с видом от первого лица, трехмерной графикой и каждой фигурой, имеющей собственное лицо, причем сражение проходит в прекрасной долине, где игровое поле покрыто изумительно анимированной травой, под которой клетки доски едва различимы. Оценка «5+» за внешний вид гарантирована, и вашему удивлению нет границ, но я не знаю, каким должен быть интерфейс, чтобы играть в это чудо!

Особенности

Технология, лицензии и прочие «примочки», важные для рекламы продукта и подчеркивания его уникальности на рынке («Отображение 40000 полигонов в реальном времени!..»), должны касаться программиста в последнюю очередь. Весь мой опыт разработки видеоигр свидетельствует, что игры никогда не делают из «дополнительных возможностей», однако почему-то именно на них многие разработчики основывают свои представления об играх.

Когда, читая проектную документацию к игре, видишь лишь пространные псевдонаучные рассуждения, умело упрятавшие суть - идею игры, это выглядит несколько странно. Я сказал «псевдонаучные» поскольку, несмотря на вечные обещания точности, там растут лишь неясные научные дебри. Что означает фраза: «движение 40000 полигонов»? Или «захват движения»? Или «искусственный интеллект»? Даже если мы верим, что знаем, о чем говорим, последнее слово за реальностью. Я помню, когда мы работали над проектом HeadHunter, мой партнер Хавьер Аревало (Javier Arevalo) создал технологический прототип, содержащий множество трехмерных возможностей, от которых тогда просто отвисала челюсть: вспышки, цветное освещение, точечные эффекты. Люди, видевшие это, кричали: «Потрясающе! Теперь осталось придумать, как все это вставить в игру!» Сущие пустяки: всего лишь написать игру...

В заключение Гонзо Суарес приводит аналогию: «Приукрасить игру дополнительными функциями - это все равно, что поставить на машину спойлеры и литые диски: если автомобиль не удовлетворяет своему назначению, все эти аксессуары никому не нужны».